Hello everyone.
I will be sharing this topic with you.
The topic I will be talking about is Bridge Attack.
Let me introduce myself first.
I am a security researcher from Tencent's mobile security lab, Razer Team.
My name is Han Zidong.
My main research focus is on the security of mobile apps and IoT.
Last year, I participated in the Black Hole Challenge in the 2018-2024 G-BON competition.
I successfully completed the challenge.
After participating in the challenge, I thought about the security of IoT and the security of mobile apps.
I thought about the security of IoT and the security of mobile apps.
I am lucky to have the opportunity to share this with you today.
The topic I will be talking about today is the concept of Bridge Attack.
Then, I will introduce you to why I chose Bridge Attack.
What is the difference between Bridge Attack and Bridge Attack?
The third topic I will be talking about is...
I will show you how to use Bridge Attack to complete a complete attack and some real use cases.
Finally, I will introduce you to how to deal with the risk of Bridge Attack.
What kind of prevention measures should we take?
First, let's take a look at the definition of Bridge Attack.
First, we need to understand what is Bridge.
Speaking of Bridge,
we have to mention the fast-growing mobile development and IoT related fields in recent years.
The picture on the left is a hybrid app.
It is actually a combination of the traditional native app and the web app.
It uses H5 to make the development cycle and the development efficiency faster and higher.
Basically, it has become the mainstream of a lot of native app development.
The IoT on the right is the Internet.
You should be more or less aware of this.
Our Bridge is actually based on these two backgrounds.
Let's take a look at it.
This Bridge is actually a abstract concept.
In this browser and mobile apps and IoT devices,
there is actually a abstract Bridge.
It is used for data or communication.
For mobile apps,
the most familiar one is the web view on Android.
This web view is the communication between JS and Java from H5 to native.
In fact, there is also such a web view on iOS.
Like the previous UI web view,
and the later WK web view.
For IoT devices,
what is the abstract Bridge that we need to consider?
In fact, there are a lot of basic agreements at the bottom.
For example, the DLNA projection agreement,
the UPnP machine-to-machine user agreement,
or the agreement that manufacturers use WebSockets or TCP
to define their own communication and interaction.
We also gave an unofficial definition of Bridge attack.
In fact, it uses the JS Bridge in the app
and the projection agreement layer in the IoT,
so that the attacker has such an opportunity
to use this Bridge to achieve its effect on mobile apps
or IoT devices.
Let's take a look at
why we choose this direction of attack as a research point.
First of all, let's take a look at the security risks
that WebViewer has exposed in the past.
Let's take a look at the risks in the past.
In 2012,
CVE-2012-6336 revealed the classic
long-term use of the JavaScript interface interface.
The source of such long-term use of JavaScript
This is a long-term use of JavaScript.
This is a long-term use of JavaScript.
This is a long-term use of JavaScript.
This is a long-term use of JavaScript.
Now, the next.
The latter.
Now.
We have a series of related CEL files
for the centralized operation of the WebViewer.
It's a lot out of the box.
There's a classic one,
a classic case of an application
or comment.
In fact, it's also used this kind of risk
to do an extension.
The last one is the attack of the UIL Scammer.
In fact, in recent years,
a lot of researchers have also shared this in many security conferences.
In fact, the attack of the UIL Scammer
is a very good cut-in entrance in BridgeAttack.
We will talk about this later.
Let's take a look at the difference between BridgeAttack.
First of all, compared to the previous WebView,
it has more attack surface.
Secondly, the looping effect it produces
is directly related to the ability of the UIL Bridge.
That is to say, the stronger your Bridge ability is,
the greater the effect of the looping you produce.
The last one is that it not only covers the mobile app,
but also covers the security of IoT.
Let's take a look at
how to use
such a BridgeAttack and some real cases.
First, let's look at the BridgeAttack attack surface
as a cut-in point for mobile applications.
From the browser, as an attack jump board,
the attacker can launch an attack from the outside payload.
Using the Scammer analysis process,
it cuts into the WebView and the phone,
and it can attack the app from the outside.
Then, it makes a
In the follow-up operation work of Scammer analysis,
there is a problem.
Due to the security of WebView,
many of the manufacturer is the developer of the app
actually has respect for this.
It will do a comparison.
It will add a layer of identity verification.
It will not let random attackers
to randomly pick up the interface capability provided by WebVL.
Then we have to consider how to go around
the process of identity identification.
There are three common and easy-to-use solutions.
The first one is XSS attack.
This is basically an unobtrusive way of attacking the web.
The second one is an audit of the domain name.
You can see that when filtering the domain name,
many developers or manufacturers
did not make a strict protection.
You can ask for an exaggeration like this.
The third one is to attack the middleman.
For example,
you can make an exaggeration like this
by asking for the JS Bridge file
sent by the JTDP.
Let's take a look at the first case
about an unobtrusive audit domain name.
In this case,
this developer is a head application.
This is a domestic head application.
He is trying to solve the problem
by using the code that the programmer has analyzed.
When the attacker is analyzed,
he made a judgment.
He decided that if the domain name of the other party
contains a new subdomain name,
he used contents as a filtering condition.
If there is a new domain name,
he thought it was safe.
If there is no such thing,
he would turn off all JS capabilities.
We can actually see this attack flow
through this picture above.
When you use contents and endways
as a filtering method,
there is no way to prevent the false domain name in front.
That is to say,
bypassing bypass is invalid.
And in our research results,
this kind of situation
actually accounts for a lot.
After we bypassed such a domain name detection,
we need to further reverse analyze its code.
We can see that
this part of the domain name
is the JS bridge provided by the other party.
In this app,
it provides such an ability
called sendClientRequest,
which is to send this request to the server
through the client's website.
Then,
we use the ability of this JS API
to achieve a deep-level cross-border attack
through a simple web-level attack.
Then,
we use this interface
to send a fake request to the server.
Then,
we get the order information of this user
as well as his personal identity,
including his identity number.
In fact,
such an attack
starts from a URL.
In the end,
the attack of the web and the attack of the app
are linked together.
This is also a head application.
This level is higher than the previous one.
During the audit process,
we found that
the domain name of this app
is very different from the previous one.
It has a very strict domain name audit process.
However,
the problem is that
it is not effective in protecting XSS.
Of course,
XSS is not something that can be protected.
During the audit process of this app,
we found that
under a certain domain name,
there is such an XSS.
If we consider this XSS
from a simple external point of view,
we can use its cookie
to do some things.
But there is a problem here.
Nowadays,
many head companies
when you get the cookie value
to do an audit,
there are many second tests on the client's end.
For example,
the second password
or the second ticket test.
Then it is difficult for you
to achieve some deeper information.
For example,
payment information,
orders,
or a series of things.
How can we expand this place further?
Let's think about
how to design a payload.
We use this XSS
to import a JS file from the outside.
In this JS file,
we are going to use
the ability of this bridge
provided by this app itself.
We found some very sensitive
and very dangerous JS APIs
exposed outside.
Finally,
we use a malicious URL
to achieve this sensitive information.
This is a simple POC.
First,
we import the JS API file from the outside.
Then,
we find the first sensitive
JS bridge interface
called getUserInfo
to get the cookie
and some keys in the cookie.
Then,
we use this key
to use another sensitive interface
in this app again,
sendRequest,
to do a deep-level call.
In the first round,
we use this key
to get the user's payment information.
Finally,
to summarize,
in this bridge attack in the app layer,
the attacker can use a simple URL
to use this virtual JS bridge
to integrate the web view
and the security risk
of the native layer.
Then,
more attacks are exposed.
Then,
it has more and better conditions
to use the ability of this JS bridge
to achieve the ability
to retrieve information
and code execution,
and even the possibility
of wireless transmission.
After talking about
this bridge attack in the app,
let's take a look
at the difference between
the bridge in IoT
and the bridge in the app.
So,
we mentioned that
in the IoT bridge,
it is more focused on two characteristics.
The first characteristic
is the penetration of the internal network.
Then,
it can use an attack method
such as DNS reset,
or
it can use the central control app
which is
for every smart component,
it has to have a corresponding app
as its management center,
the brain app.
Then,
we can attack this central control app
and it can also achieve
a penetration effect.
Then,
there is another characteristic.
That is,
in the use of the IoT bridge,
it can achieve a better
and more lasting effect.
Then,
it brings two advantages.
The first one is that
you may have more meat
to choose from
Then,
the second one is that
you have more time
to help you design
and construct
the attack result
and the attack idea.
Then,
let's take a look
at the IoT bridge.
The IoT bridge
is actually related
to this architecture.
Then,
for this
IoT bridge,
IoT manufacturers with cloud servers
often interact with
the cloud end
in virtual bridge
in many cases.
Then,
in this case,
the bridge
is actually
often not
what we are concerned about
in this topic.
Then,
what we are more concerned about
is that
there is no cloud server like this.
In other words,
an agreement
with this app
and this IoT device
to negotiate in advance
may be
UPNP.
It may be
WebSocket.
It may also be
other applications
that some manufacturers
have customized
as a bridge
or a bridge
data communication process.
Then,
let's take a look
at some of its
bridge attacks
in the IoT device.
First of all,
it only lists
the example
of DNS remodeling.
By using
DNS remodeling,
we reached the first step
and infiltrated the internal network.
Next,
we can analyze
this hardware
and
look at
the open port
and
we can determine
the agreement
that the bridge
has achieved.
For example,
UPNP,
DLNA
or other agreements.
Then,
when we reach
this agreement,
we can better
construct
this kind of
attack request
in the format
to achieve our goal.
Then,
we can see
that there is a difference
the attack
of this app
and
the process
of identity certification
that it missed.
This is because
among the IoT manufacturers,
there are relatively
few manufacturers
that are aware of this
and do identity verification.
In other words,
their attention
should be
lower than
the first level
of ABP.
Let's look at
the first case of
bridge attack
in IoT.
This case
is a DLNA case.
DLNA is
an investment agreement
that is,
mobile phones
or some multimedia
are invested
in the TV market.
In this case,
the target of this IoT device
is a smart TV.
Then,
this smart TV,
first of all,
in the implementation
of the DLNA agreement,
it did not
do identity verification.
Then,
we as attackers
can use
its basic functions
at will.
For example,
you watch TV at home,
I can log in
and play
some other
images
or other
videos
at will.
Then,
in addition
to this way,
it seems that
the threat of DLNA
is not very...
the attack of
bridge attack
is not very big.
However,
this manufacturer
in addition to
this basic
agreement,
it also
made some
expansion.
In other words,
it helped
the DLNA agreement
for its own
for its own
some
some
some
aspects.
It made some
expansion.
Then,
it provides
a series of
interfaces in it
to achieve
the process of
long-term download,
execution,
and verification.
In this way,
we as attackers
can also
construct
such an attack chain.
We use
its
unsafe
bridge
to achieve
the purpose of our attack.
Finally,
it enters the private network
and hits
our code.
Here is
the second
case of
bridge attack.
This is
also
a TV manufacturer.
But this TV manufacturer
changed
thinking
about
this.
We first
analyzed
its
central control
app.
After analyzing
this central control
app,
we found that
it was not protected
by the code.
Then,
we easily
obtained
the agreement
and some
specific
format
in its agreement.
Then,
we found
the websocket
of Wireshark
that
it is
through
Websocket
it can
the
remote
download
and
operation
process.
Of course,
it also
did not
do any
verification.
After
looking
at
the
bridge
and
IoT,
let's
think
about
how
we can
prevent
this attack.
Then,
I think
first of all,
for the app,
that is,
the JS Bridge,
we need to
strictly
verify
this identity.
Just like
the contents
or
as with,
at least,
do not appear again.
Then,
the second thing is that
we have to make an agreement
with the ability of this bridge.
For example,
there is an attack of XSS.
You say I just
can't prevent
all the XSS
to be blocked.
It doesn't matter.
You don't set
the whole line
domain
to be very large.
Then,
you can make the whole line
into a
sharp
division.
Even if it gets
the XSS of a specific domain,
it can't get
all the
ability of this
bridge.
In this way,
it can also
make a limit limit.
Finally,
try to use
this HTTPS
or some encrypted signals
to ensure
that the middleman is not attacked.
For the
IoT bridge,
we
consider more
the same strategy
and the JS bridge.
In addition,
we also need to be careful.
For manufacturers,
we still don't
try to abuse
the ability of
this bridge
to expand
this basic agreement
randomly.
If you really
want to expand it,
make sure
you must
add this
possible
test
part.
Finally,
I will
make a summary
of this sharing.
Regarding
the bridge
attack,
first of all,
it has more
target options.
For example,
more
apps
and IoT
can be your
target.
Secondly,
for us attackers,
from the perspective
of bridge attack,
to analyze
the risk,
we have more
attack
aspects
to consider.
We can easily
integrate
the security
of web attacks
and apps
and IoT
together.
Thirdly,
it is very easy
to use.
By using
a malicious
URL,
it can achieve
a fast
and wide
transmission
Finally,
it can use
the results
such as
long-term
use,
local
use,
or
information
leakage
and even
continuous
attack.
Thank you
for
sharing
with me.
See you next time.
Bye.
Bye.
